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INTRODUCTION 

The  U.S.  Navy  is  undergoing  a  major  information  technology  transformation  to  meet  the 
changes  in  its  operational  commitments  and  to  ensure  that  necessary  operational  and 
intelligence  information  is  delivered  to  the  “right  person,  at  the  right  time,  and  in  the  right  way.” 
Naval  missions  have  expanded  beyond  those  traditionally  served  with  increased  emphasis 
placed  on  non-traditional  mission  areas  such  counterterrorism,  maritime  security, 
counterinsurgency,  civil-military  operations,  information  operations,  security  cooperation,  and 
humanitarian  relief  in  areas  with  limited  or  no  information  network  support.  The  Navy  is  also 
required  to  interoperate  with  other  U.S.  military  services,  U.S.  governmental  agencies,  and 
international  partners.  In  this  new  environment,  information  is  no  longer  an  enabler  but  is  a  core 
war-fighting  area. 

In  December  2009,  the  Chief  of  Naval  Operations  (CNO)  issued  his  vision  for  Information 
Dominance,  reference  (a),  defining  it  as:  “the  ability  to  seize  and  control  the  information  domain 
high  ground  when,  where  and  however  required  for  decisive  competitive  advantage  across  the 
range  of  Navy  missions.”  The  responsibility  for  Information  Dominance  was  assigned  to  the 
Director  for  Information  Dominance,  a  new  organization  that  is  the  convergence  of  the  former 
N2  (Intelligence)  and  N6  (Command,  Control  and  Communications)  directorates.  This  new 
directorate  is  responsible  for  making  programmatic  investment  decisions  for  information,  cyber 
and  space  capabilities,  and  for  developing  the  Navy’s  information  architecture.  The 
responsibilities  also  include  achieving  the  integration  and  innovation  necessary  for  warfighting 
dominance  across  the  full  spectrum  of  operations  across  the  maritime,  cyberspace  and 
information  domains. 

PMW-150  provides  Command  and  Control  (C2)  systems  to  the  U.S.  Navy’s  command 
centers,  ships,  and  submarines.  Commencing  in  2010,  PMW-150  is  undertaking  a  new 
strategic  initiative  with  the  intent  to  dramatically  change  the  functional  capabilities  of  the  Navy’s 
maritime  C2  systems  while  fundamentally  changing  the  software  development  and  delivery 
processes.  For  too  many  years  maritime  C2  has  suffered  from  issues  that  deal  with  the 
software  development  and  acquisition  process.  PMW-150’s  near-term  transitional  solution  will 
lead  to  sustained  information  superiority  at  a  reduced  Total  Ownership  Cost  (TOC).  In  simplistic 
terms,  the  PMW-150  Maritime  C2  Strategy  has  three  primary  objectives: 

1 .  Provide  Mission  Management  Capabilities.  Historically,  Navy  C2  systems  have  been 
used  to  simply  provide  “Who  and  Where”  information  to  various  battle  commanders. 
Future  C2  systems,  need  to  fulfill  the  “Operational  Level  of  War”  (OLW)  requirements 
presented  in  the  Maritime  Operations  at  the  Operational  Level  of  War,  reference  (b),  will 
need  to  provide  timely  What,  When,  Where  and  How  information,  in  addition  to  Who  and 
Where. 

2.  Transition  from  Stove-Piped  Solutions  to  Net-Centric  Operations.  PMW-150’s  C2 
capabilities  have  been  developed  as  unique  stove-piped  products,  with  their  own 
development  and  sustainment  funding  lines  and  program  infrastructure.  Maintaining  and 
improving  a  large  number  of  different  baselines  has  become  prohibitively  expensive, 
resulting  in  some  baselines  going  into  caretaker  status  and  new  capabilities  being 
fielded  in  only  a  limited  number  of  locations  and  platforms.  To  reduce  the  cost  of 
maintaining  and  improving  C2  baselines,  PMW-150  has  adopted  a  component  portfolio 
approach  to  C2  system  software  acquisition.  Component  technologies,  including  service 
oriented  architectures  (SOA),  virtual  machines,  and  Web  2.0  technologies  provide  a 
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foundation  for  systems  to  be  decomposed,  decoupled,  and  recomposed  as  a  portfolio  of 
independently  managed  components.  The  portfolio  will  share  a  common  architecture 
and  be  developed  from  a  set  of  common,  reusable  software  components. 

3.  Establish  Government  Ownership  and  Technical  Control  of  Software  Acquisition 
Processes.  The  iterative  nature  of  incremental  component  software  development  and 
the  migration  to  net-centric  operations  require  a  different  set  of  software  acquisition 
processes.  PMW-150  has  established  the  Rapid  Integration  and  Test  Environment 
(RITE)  to  facilitate  needed  process  change.  RITE  is  a  new  life  cycle  model  for  Navy  C2 
software  that  places  increased  emphasis  on  early  and  frequent  software  testing,  as  well 
as  necessary  software  engineering  practices  at  the  source  code  level.  RITE  is  a  more 
structured  approach  to  software  development,  taking  full  advantage  of  technology 
advances  and  open  source  models  to  automate  processes  and  shorten  development 
cycles  -  thus  increasing  the  maintainability  of  the  software  baselines.  The  initiative  also 
clarifies  software  delivery  requirements,  adding  additional  engineering  rigor  to 
deliverables  and  reducing  opportunity  for  misunderstanding  between  customers  and 
developers.  Its  goal  is  to  reduce  overall  cost,  streamline  delivery  of  quality  C2  software 
and  ultimately  to  resource  focus  toward  the  early  stages  of  the  life  cycle  where  the  return 
on  investment  is  maximized.  RITE  provides  comprehensive  oversight  of  software 
development  from  initial  product  design  to  customer  acceptance. 

These  three  strategic  objectives  are  the  subject  of  this  paper  and  are  presented  in  detail 
below.  It  is  important  to  highlight  that  the  maritime  C2  development  environment  is  dynamic  and 
therefore  information  presented  is  subject  to  change  as  the  strategy  is  implemented.  For 
current  program  information,  readers  should  contact  the  PMW-150  C2  Program  Office. 

MISSION  MANAGEMENT  CAPABILITIES 

The  goal  of  C2  is  to  maintain  alignment  and  provide  status  on  the  progress  of  the  command 
plan.  Mission  management  is  the  method  for  achieving  and  exercising  these  command  and 
control  functions  at  the  “Operational  Level  of  War”  (OLW)  and  below.  The  DoD  Dictionary, 
defines  “mission”  as  a  “task,  together  with  the  purpose,  that  clearly  indicates  the  action  to  be 
taken  and  the  reason  therefore”. 


•  A  “mission  statement”  is  a  short  sentence  or  paragraph  that  describes  the  organization’s 
essential  t§sk  (or  tasks)  and  purpose  -  a  clear  statement  of  the  action  to  be  taken  and 
the  reason  for  doing  so.  The  mission  statement  contains  the  elements  of  who,  what, 
when,  where,  and  why,  but  seldom  specifies  how.  ” 

So,  by  inference,  Mission  Management  is  defined  as: 

•  Planning,  executing  [directing,  monitoring]  and  assessing  achievement  of  the  intended 
purpose  of  a  mission* ....  AND 

•  Managing  multiple  missions  while  continuing  to  prioritize  available  resources,  targets, 
and  objectives  to  mass  activities  in  time,  space,  and  purpose  at  the  decisive  times  and 
places. 

PMW  150  and  its  predecessor  organizations  have,  with  a  single  mindedness,  concentrated 
the  focus  of  Global  Command  and  Control  System  -  Maritime  (GCCS-M)  on  track  management 
and  track  dissemination,  to  include  a  limited  number  of  mission  applications.  While  reliance  on 
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track  management  and  track  dissemination  is  a  crucial  element  of  our  maritime  C2  architecture, 
it  alone  does  not  satisfy  our  primary  role  as  the  Navy's  C2  Program  for  instituting  Mission 
Management  capabilities. 

Our  mission  now  and  into  the  future  is  to  emphasize  and  build  the  means  to  allow  the  naval 
OLW  commanders  (Fleet,  Numbered  Fleet,  Naval  Joint  Task  Force  (JTF),  Joint  Force  Maritime 
Component  Commander  (JFMCC)  and  subordinate  commanders  (Cruiser-Strike  Group  (CSG) 
Commanders,  Naval  Expeditionary  Force  Commanders,  Amphibious  Task  Force  (ATF)/Landing 
Force  Commanders,  Destroyer  Squadron  (DESRON)  Commanders  and  individual  platform 
commanders)  to  deploy  personnel  and  equipment  through  a  set  of  requisite  tools  to  enable  the 
Navy  command  structure  to  plan,  execute,  monitor,  and  assess  its  mission  requirements.  The 
scope  of  the  objective  described  herein  covers  not  only  the  primary  elements  of  PMW-150’s 
product  line  (C2  Planning  &  Decision  Making,  Situational  Awareness,  Combat  Support)  but  also 
shows  the  intersection  with  the  phasing  of  products  from  Intelligence,  Surveillance,  and 
Reconnaissance  (ISR)  and  with  the  computing  and  enterprise  services  of  Program  Executive 
Office  for  Command,  Control,  Communications,  Computers  and  Intelligence  (PEO-C4I)  and 
external  systems  developments  such  as  those  of  the  Joint  C2  programs. 

Figure  1  represents  PMW  150’s  objective  for  the  mission  management  evolution  and  is 
driven  by  Navy  Doctrine,  specifically  NWP  50-1  Navy  Planning  and  NWP  3-32  Maritime 
Operations  at  the  Operational  Level  of  War.  Therefore,  It  is  closely  tied  to  the  six  Commander’s 
Control  Areas  presented  in  NWP  3-32  and  provides  growth  in  C2  component  functionality 
beyond  the  current  area  of  Situational  Awareness  (SA).  It  does  it  in  a  way  that  extends  the 
Commander’s  control  areas  from  the  OLW  level  down  to  the  task  force,  task  group,  task  unit, 
and  individual  platform  while  preserving  maximum  self-synchronization  at  each  level  of 
operations  within  the  constraints  of  the  control  measures  and  control  actions  within  each  of  the 
areas.  The  additional  fundamentals,  referred  to  in  reference  (b)  as  “Control  Areas”,  include 
Maintain  Alignment,  Advance  the  Plan,  Comply  with  Procedure,  Counter  the  Enemy,  and  Adjust 
Apportionment.  These  six  fundamentals  of  C2  are  described  below  and  contribute  to  the 
Commander’s  decision  cycle  and  the  mission  management  requirement. 

Decision  Cycle 

The  Navy’s  C2  mission  management  objective  is  tied  directly  to  the  need  to  provide 
Commander’s  the  information  necessary  to  make  critical  decisions  and  take  decisive  actions. 
The  Decision  Cycle  is  presented  in  NWP  3-32,  reference  (b)  and  consists  of  the  actions: 
assess,  plan,  direct,  and  monitor.  It  “assists  the  commander  in  understanding  the  operational 
environment  and  executing  operational  design  during  campaign  preparation  and  execution.” 
“Operational  commands  assess  how  they  are  doing,  conduct  planning  based  on  this 
assessment,  direct  forces  as  needed  to  execute  the  plan,  and  monitor  force  execution  and  its 
impacts  on  the  adversary.”  “Outputs  of  monitoring  provide  inputs  for  the  next  round  of 
assessment.” 

It  is  important  to  note  that  the  decision  cycle  (and  Mission  Management)  can  occur  at  any 
echelon  of  strategic,  operational,  or  tactical  command  (or  at  a  combination  of  levels  as 
necessary  to  successfully  achieve  the  mission  purpose  and  desired  end  state.  Because  Navy 
doctrine  promotes  a  great  degree  of  distribution  in  operational  planning  and  execution,  new 
tools  are  needed  to  enable  force  level  oversight  of  these  dispersed  operations.  It  is  the  goal  of 
the  Mission  Management  objective  to  provide  the  information  necessary  for  informed  decisions. 
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Figure  1.  PMW-150’s  Strategy  for  Maritime  C2  Transformation 


Control  Areas 

Navy  operational  commander’s  control  actions  are  categorized  by  the  six  control  areas 
shown  in  Figure  1.  These  control  areas,  presented  in  NWP  3-32,  are  restated  in  Table  1: 

Table  1:  Mission  Management  Control  Areas 


Control  Area 

Description 

Maintain  Alignment 

“The  operational  commander’s  task  is  to  ensure  that  all  execution  decisions  and 
apportionment  requests  remain  aligned  with  the  operation’s  mission  statement  and 
commander’s  intent  (purpose,  sequence,  end  state  and  priorities).  There  must  be  a 
direct  correlation  between  the  higher  headquarters  commander’s  intent  and  goals  and 
the  operational  commander’s  guidance  and  the  plan  formulated  to  accomplish  the 
mission.  All  direction  during  plan  development  and  execution  should  support  the  mission 
statement  and  commander’s  intent.” 

Provide  Situational 
Awareness  (SA) 

“Traditionally  the  control  area  is  what  Navy  C2  has  best  supported.  The  operational 
commander  must  assess  the  status  of  plan  execution  constantly.  Using  the  available 
common  operational  picture  (COP)  and  communications  and  intelligence,  the  operational 
commander  must  determine  whether  friendly  force  disposition  is  in  accordance  with  the 
plan,  whether  enemy  force  disposition  is  in  accordance  with  expectations,  and  whether 
forces  are  executing  according  to  the  plan  and  procedures.” 
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Control  Area 

Description 

Advance  the  Plan 

“The  operational  commander  must  monitor  all  aspects  of  the  plan  execution  against  the 
timeline.  This  infers  detailed  knowledge  of  all  elements  of  the  plan  (enemy  and  own 
force  disposition,  branches,  and  sequels).  Rarely  are  plans  executed  without  deviation. 
When  an  unanticipated  condition  is  encountered,  the  tactical  or  on-scene  commander 
must  adjust  the  plan  correspondingly.  The  goal  is  to  have  every  decision  and  every 
direction  move  the  plan  forward  on  the  time  line,  toward  the  desired  end  state.  The 
operational  commander  is  responsible  for  attaining  this  goal.” 

Comply  with 
Procedure 

“In  monitoring  execution,  the  commander  oversees  compliance  with  doctrinal  Tactics, 
Techniques,  and  Procedures  (TTP),  Operation  General  matter  (OPGEN),  Operation 
Tasks  (OPTASKs),  special  instructions,  Standard  Operating  Procedures  (SOPs),  and 
intentions  to  avoid  blue-on-blue  engagements  and  achieve  efficiencies  in  plan  execution. 
As  an  example  of  a  procedure,  the  commander  and  staff  must  have  an  in-depth 
knowledge  of  the  Rules  Of  Engagement  (ROE),  and  when  the  need  exists  for  requesting 
supplemental  ROE  in  order  to  properly  execute  the  plan,  the  commander  and  staff  need 
to  know  the  procedure  for  making  this  request.” 

Counter  the  Enemy 

“Intelligence  Preparation  of  the  Operational  Environment  (IPOE)  and  knowledge  of 
enemy  capabilities  result  in  assumptions  regarding  probable  enemy  objectives  and 
Courses  Of  Actions  (COAs).  The  operational  commander  must  be  responsive  to 
emerging  intelligence,  surveillance,  and  reconnaissance  information  that  differs 
significantly  from  expectations  and  be  prepared  to  adjust  the  plan  in  execution.  Knowing 
what  the  enemy  is  doing  at  all  times  and  being  quick  to  countermove  on  receipt  of 
reliable  information  is  perhaps  the  number-one  goal  of  C2.” 

Adjust 

Apportionment 

“Ground  forces;  ships;  aircraft;  air  space;  command,  control,  communications;  computer 
infrastructure;  and  time  all  are  apportioned.  Any  changes  in  asset  availability,  attrition, 
on-scene  requirements,  priorities,  enemy  disposition,  or  enemy  tactics  may  trigger  a 
need  for  reapportionment.  The  operational  commander  must  monitor  these  changes, 
anticipate  requests,  and  be  prepared  to  adjust,  as  necessary,  to  advance  the  plan.  Of  all 
the  apportionment  factors,  the  one  most  frequently  adjusted  is  time.  It  is  almost 
inevitable  that  the  operational  commander  will  be  faced  with  several  decisions  regarding 
allotting  more  time  to  accomplish  the  plan.  Very  often  the  operational  commander,  who 
knows  what  is  occurring  across  all  forces  and  can  judge  the  consequence  of  a  change  in 
timing  in  one  force,  is  in  the  best  position  to  make  the  call.” 

The  development  of  the  informational  components  needed  to  perform  the  decision  cycle  will 
be  discussed  in  more  detail  in  the  next  Maritime  C2  strategic  objective  discussed  below. 

STOVE-PIPED  SOLUTIONS  TO  NET-CENTRIC  OPERATIONS 

The  transformation  from  stove-piped  networks,  systems  and  processes  to  a  net-centric  SOA 
is  central  to  the  Maritime  C2  Strategy.  The  transformation  will  be  accomplished  through  an 
incremental  development  approach  where  each  increment  provides  a  set  of  militarily  useful  and 
supportable  operational  components.  The  architecture  will  support  incremental  development, 
adaption,  and  adoption  that  allow  additional  components  or  higher  performing  implementations 
of  existing  components  to  be  added  to  the  architecture  over  time.  Life  cycle  management  is 
required  for  multiple  versions  of  components,  including  the  enforcement  of  network  exchange 
compatibility  or  maintaining  older  versions  until  all  platform  baselines  have  been  updated  to 
newer  versions. 

The  desired  end  state  of  executing  the  PMW-150  Maritime  C2  Strategy  is  that  PEO-C4I 
fields  a  system  which  is  capable  of  integrating  all  aspects  of  Navy  C2  doctrine  throughout  the 
operational  and  tactical  levels  of  war.  That  implies  a  net-centric  system  which  is  based  on 
sharing  of  information  among  the  maritime  platforms,  combined  with  collaborative  and 
enhanced  shared  awareness  to  enable  centralized  guidance  from  the  Operational  level  and 
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distributed  execution  at  the  Task  Force  and  Task  Group  and  below.  A  depiction  of  the 
connected  C2  data  and  applications  envisioned  in  the  desired  end-state  is  shown  in  Figure  2. 
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Figure  2:  Desired  End-State:  Connected  C2  Data  and  Applications 

The  Maritime  C2  Strategy  requires  policy  changes,  commitment  to  embracing  interoperable 
architectures,  and  adopting  SOA.  SOA  is  a  style  of  systems  design  using  loosely  coupled 
connections  among  independent  programs  to  create  scalable,  extensible,  interoperable, 
reliable,  and  secure  systems.  A  SOA  design  approach  requires  the  following  effort: 

•  Identify  and  address  gaps  in  existing  data  management  systems; 

•  Create  interoperability  across  data  types,  disciplines,  space  and  time  scales,  etc; 

•  Develop  and  adopt  standards  for  data  access  protocols  and  data  formats; 

•  Develop  and  adopt  standards  for  terminology,  units  and  quantity  names; 

•  Improve  integration  of  measurements,  data,  and  products; 

•  Define  a  Data  Management  Architecture  to  integrate  existing  systems  and 

•  Provide  a  framework  to  meet  needs  of  future  data  systems; 

•  Improve  the  efficiency  of  business  by  eliminating  barriers  to  information;  and 

•  Access  and  reduce  duplication  through  development  and  implementation  of  an  SOA 
framework. 

Maritime  C2  Architecture. 

The  future  maritime  C2  architecture  is  shown  in  Figure  3  and  is  detailed  in  reference  (c). 
This  architecture  is  used  to  drive  the  development  of  the  various  components  and  to  ensure  that 
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new  components  meet  the  functional  requirements  needed  to  support  the  Commander’s 
decision  cycle  while  also  interfacing  with  legacy  systems  (hardware  and  software)  for  the 
foreseeable  future. 

Infrastructure  Layer 

The  long-term  goal  of  the  PMW-150  Architecture  is  to  build  C2  capabilities  that  operate  in 
conjunction  with  the  Enterprise  Infrastructure  Layer.  The  Enterprise  Infrastructure  serves  two 
key  functions.  (1)  It  provides  a  Computing  Tier  that  provides  the  computing  infrastructure  on 
which  PMW-150  developed  capabilities  will  operate  and  (2)  it  provides  an  Enterprise  Service 
Tier  that  provides  key  enabling  services  (e.g.,  security,  discovery,  messaging,  etc.)  necessary 
for  a  SOA  to  operate.  PMW-150  developers  will  not  produce  any  hardware  or  software  in  the 
Enterprise  Infrastructure  Layer,  but  are  required  to  understand  how  their  software  will 
interoperate  with  it. 


r 


Maritime  C4f  Capabilities  ( PEO-C4I ) 
_ 


Maritime  C2  Capabilities  (PMW-150) 


Presentation  Tier 


Composition  Tier 


Service  Tier 


Data  Technology  Tier 


Enterprise  ServiceTier 

INCESJ 


Computing  Tier 

(DECCs) 


Core  ServicesTier 

(CANES  Core  Services) 


E 

aj 


ru 

or 

a> 


§ 

£ 


o 

O 

Ul 

CL 


Computing  Tier 

(CANES  Common  Computing  En/ironment) 


"V 

Joint  SOA  Stack 
(DJSA) 


V_ 


U 

O 


V 

tycvy  SOA  Slack 
(PMW-160) 


Figure  3.  Component  Architecture  View  of  the  Future  C2  Architecture 

As  indicated  in  Figure  3,  the  Enterprise  Infrastructure  is  divided  into  two  stacks.  The  primary 
stack  for  PMW-150  capabilities  is  the  Navy  SOA  Stack.  It  will  be  deployed  aboard  ships  and  at 
numerous  naval  shore  facilities.  The  Navy  stack  is  being  built  and  fielded  by  the  CANES 
program  under  the  direction  of  PMW-160.  All  PMW-150  developed  capabilities  are  required  to 
operate  on  the  Navy  SOA  stack.  Some  of  the  C2  capabilities  developed  by  PMW-150  will  need 
to  meet  Joint  requirements,  as  well  as  Navy  requirements.  In  cases  where  PMW-150  is 
developing  a  Joint  C2  capability,  it  will  need  to  ensure  that  it  runs  in  the  Joint  SOA  stack,  as  well 
as  the  Navy  SOA  stack. 

Legacy  Layer 
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The  SOA-based  PMW-150  future  C2  Architecture  will  need  to  interoperate  with  legacy 
systems  for  some  time  into  the  future.  The  Legacy  Systems  Layer  is  intended  to  account  for  the 
existence  of  Legacy  Systems  and  show  how  they  relate  to  the  other  parts  of  the  SOA 
architecture.  Within  the  PMW-150  future  C2  Architecture  there  are  four  key  interface  points: 

•  Legacy  System  -  Computing  Tier  interface  point.  Legacy  Systems  developed  by 
PEO  C4I  (including  PMW-150)  will  run  on  top  of  an  externally  provided  Computing  Tier 
(either  Navy  or  Joint). 

•  Legacy  System  -  Data  Technology  Tier  interface  point.  Data  contained  within 
Legacy  Systems  can  be  ingested  into  the  data  technology  tier.  This  is  typically  done 
when  there  are  operational  and/or  performance  benefits  to  be  gained  by  bringing  legacy 
data  into  the  more  modern  Data  Technology  Tier  to  support  SOA-based  operations. 

•  Legacy  System  -  Service  Tier  interface  point.  In  many  cases  it  is  useful/cost 
effective  to  construct  a  service  based  mechanism  for  delivering  functionality  or  data  from 
an  existing  Legacy  System  to  the  enterprise.  In  this  case,  software  within  the  Service 
Tier  interacts  with  the  Legacy  System  using  legacy  APIs  and  then  in  turn  provides  a 
service-based  interface  for  delivering  that  functionality  to  consumers.  This  evolutionary 
approach  is  often  the  fastest  and  most  cost  effective  way  to  provide  a  SOA-compliant 
method  for  delivering  capabilities  encapsulated  in  Legacy  Systems. 

•  Legacy  System  -  Presentation  Tier  interface  point.  In  some  cases  it  is  useful  to 
embed  a  legacy  system  user  interface  as  a  component/widget/portlet  within  a  more 
comprehensive  user  interface  being  provided  by  the  presentation  tier.  The  ability  to 
embed  Legacy  systems  interfaces  is  limited  to  certain  cases.  For  example,  Legacy 
Systems  that  provide  a  web  interface  can  usually  be  easily  embedded,  whereas  other 
types  of  legacy  system  interfaces  can  be  more  difficult  to  encapsulate. 

Application  Layer 

Application  components  making  up  the  Application  Layer  will  be  developed  on  top  of  the 
Infrastructure  Layer;  these  components  consist  of  capabilities  in  one  or  more  Application  Layer 
“Tiers”,  including: 

•  Presentation  Tier.  Application  components  or  sub-components  that  interact  with  one  or 
more  users  through  display  or  user  facing  services. 

•  Composition  Tier.  Application  logic  or  complex  user  interfaces  and  workflow  processes 
built  from  a  combination  of  components. 

•  Service  Tier.  Application  components  or  sub-components  that  expose  software  service 
interfaces  that  can  be  invoked  by  a  third-party  application  to  cause  an  action  or  retrieve 
data. 

•  Data  Technology  Tier.  Data  and  technology  organized  and  exposed  to  support 
application  components  and  operational  usage.  (See  the  Data  Technology  Tier  details 
for  more  information.) 

•  Enterprise  Integration  Tier.  Common  tools  and  application  programmer  interfaces 
(APIs)  to  simplify  operation  within  the  Maritime  C2  computing  environment. 

The  key  feature  within  the  Application  Layer  is  the  Data  Technology  Tier  and  its  ability  to 
isolate  data,  data  services,  and  data  management  from  other  layers  of  the  architecture.  The 
maritime  C2  architecture  built  around  the  SOA  model  will  extend  the  C2  capability  from  just  a 
COP  to  COP-plus-new-C2  capability,  without  making  them  disjointed,  standalone  capabilities. 
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The  internal  structure  of  the  Data  Technology  Tier  consists  of  the  data,  data  storage  devices, 
database  management  software,  data  services,  and  a  data  abstraction  function. 

•  Data  and  Data  Storage.  The  physical  devices  used  to  store  data  lie  with  the  Data 
Storage  Tier  of  the  architecture.  Traditionally  C2  systems  have  stored  data  on  the  same 
physical  workstations  used  to  implement  business  logic  and  presentation  capabilities. 
The  PMW-150  future  C2  architecture  places  a  high  value  on  decoupling  the  data  from 
the  application.  The  long-term  objective  is  to  establish  a  separate  Data  Tier  where  data 
is  stored  and  managed  on  dedicated  data  storage  devices.  This  approach  has  great 
benefit  to  the  enterprise  because  it  will  eventually  allow  data  from  many  systems  to  be 
migrated  from  program  specific  hardware  to  enterprise  data  servers  -  saving  money, 
space,  and  system  administration. 

•  Data  Management.  Data  management  includes  two  categories  of  data  handling.  The 
first  category  includes  functions  that  are  unique  to  specific  data  streams/sources,  such 
as  add,  update,  delete,  some  forms  of  mediation,  etc.  These  are  performed  by  data 
specific  application  services.  The  second  category  are  functions  that  are  (or  can  be) 
data  agnostic,  such  as  relocating  a  data  store  on  the  enterprise,  backup,  replication, 
synchronization,  etc.  These  functions  are  implementation  and  performed  by 
infrastructure  services  using  parameterized  guidance  from  the  data  services  and 
processing  flows. 

•  Data  Services.  Data  services  are  mechanism  provided  by  the  data  owner  to  provide 
data  to  customers  throughout  the  enterprise.  Therefore  they  logically  fall  in  the  Service 
Tier  of  the  PMW-150  Component  Architecture.  PMW-150  future  architecture  provides 
independence  between  the  methods  of  accessing  data  (for  example,  Simple  Object 
Access  Protocol  (SOAP))  and  data  (for  example,  Electronic  Intelligence  (ELINT)  contact 
reports).  This  is  essential  to  adapt  to  warfighter  workflows,  Quality  of  Service  (QoS), 
and  continually  changing  data  delivery  methods. 

•  Data  Abstraction  Layer.  Data  Abstraction  refers  to  the  use  of  a  logical  database  view 
to  index  and  access  data  elements  from  multiple  data  sources.  This  sometimes  has 
been  referred  to  as  a  federated  data  view.  The  data  abstraction  layer  provides  data 
registration  and  discovery  services  agnostic  of  the  specific  access  method(s)  used  by 
differing  data  sources.  This  abstraction  layer  provides  a  common  data  description 
taxonomy  that  supports  registration,  search,  and  discovery  of  data  with  diverse 
characteristics,  and  methods  of  access.  The  taxonomy  can  be  extended  dynamically  as 
needed  to  support  adhoc  data  sources,  mission  applications,  and  compositions. 

Inter-Related  Common  Operating  Picture  (IRCOP)  and  User  Facing  Services 

The  Maritime  C2  developmental  roadmap  is  built  around  the  four  functional  pillars  of  C2 
Mission  Management  as  shown  in  Figure  4.  Each  pillar’s  functional  components  conform  to  the 
SOA  architecture  as  discussion  above.  The  four  pillars  are  Planning,  Execution,  and 
Assessment;  Intelligence  Collection  and  Analysis;  Intelligence,  Surveillance  and 
Reconnaissance  (ISR)  Data  Fusion;  and  Force,  Unit,  Network  Capabilities  and  Readiness. 

It  is  important  to  note  that  PMW-150  is  only  responsible  for  providing  the  functionality 
associated  with  the  Planning,  Execution,  and  Assessment  Pillar  and  therefore  must  rely  upon  on 
other  organizations  for  the  services  and  data  base  repositories  resident  within  their  respective 
pillars.  However,  for  a  net-centric  operational  approach  to  succeed  requires  that  “ALL  data  and 
information  be  universally  discoverable,  transparent  and  accessible”  as  stated  in  the  Vision  for 
U.S.  Navy  Information  Dominance,  reference  (a).  In  this  section,  we  review  the  initial 
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capabilities  being  fielded  within  each  of  these  pillars.  Note  also  that  there  are  relationships 
between  and  among  the  pillars. 
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Figure  4.  Functional  Pillars  of  Mission  Management 


The  Four  Pillars 

•  Planning,  Execution  &  Assessment  Pillar.  The  first  of  the  four  pillars  accessed 
through  the  central  technical  capability  is  the  Planning,  Execution,  and  Assessment 
Pillar.  It  leverages  a  common  data  model  and  services  (Plans/Tasks  Data  Services)  to 
increase  interoperability  of  the  planning,  assessment  and  execution  tool  set.  The  primary 
purpose  of  these  capabilities  is  to  provide  decision  support  to  the  OLW  and  below  which 
enables  centralized  guidance  and  assessment,  with  decentralized  execution  planning 
and  execution  at  the  echelons  of  task  force  and  below.  Inherent  in  that  capability,  as 
defined  by  maritime  doctrine,  are  planning  process  tools  suggested  by  NWP  5-01  (Navy 
Planning)  and  the  execution  management  tools  suggested  by  the  Commander’s  Control 
Areas  described  Table  1.  A  particular  focus  is  the  synchronization  in  time,  space,  and 
purpose  of  all  missions  to  provide  a  distributed  but  shared  view  of  all  actions  and 
resources  that  are  allocated  to  advancing  the  plan. 

Figure  5  summarizes  the  capability,  highlighted  in  yellow  that  is  being  implemented  as 
part  of  the  Maritime  C2  Implementation  Plan. 

The  key  element  of  the  Planning,  Execution,  and  Assessment  pillar  is  the 
Plans/Tasks  Data  Service  (PTDS).  The  PTDS  is  the  central  means  of  communicating 
plans  information  among  planning  &  execution  tools.  It  forces  tools  to  expose  their  data 
(i.e.,  behave  as  net  centric)  and  to  share  key  information  through  a  publish/subscribe 
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service  rather  than  by  multiple  unique  tool-to-tool  interfaces  as  is  done  today.  The  Task 
Navigator  is  the  means  of  browsing  and  editing  the  PTDS,  which  implies  that  it  also  is 
capable  of  supporting  limited  action  assignments  and  resource  designations  if  not 
covered  by  the  other  tools.  The  Plans/Tasks  (P/T)  Data  Model  (CNDE/UCore  compliant) 
does  not  contain  ALL  plan  data  but  rather  the  key  elements  that  allow  the  top  level  plan 
to  be  visible  below  -  with  links  to  more  detailed  planning  information  that  is  retained  in 
the  individual  mission  management  tools.  Because  the  PIT  data  object  is  critical  to 
maintaining  self-synchronization  at  the  unit  level  when  communications  are  disrupted 
(a.k.a.,  Disconnected,  Intermittently-connected,  or  Low-bandwidth  (DIL)  conditions),  the 
PTDS  services  are  persisted  across  all  the  major  command  platforms  and  to  selected 
unit  level  “shooters”. 
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Figure  5.  Planning,  Execution  and  Assessment  Pillar 

•  ISR  Data  Fusion  Pillar  The  second  of  the  four  Pillars,  shown  in  Figure  6,  is  ISR  Data 
Fusion  which  aggregates  C2  and  ISR  data  to  provide  the  basis  for  C2  situational  awareness. 
This  pillar  is  comprised  of  the  Open  Track  Manager  (OTM)  Shadow  COP  plus  the  entity 
relationship  enhancements  with  GCCS-I3  (Integrated  Imagery  and  Intelligence)  and  the 
Community  of  Interest  (COI)  alerting  infrastructure  as  tailored  for  Situational  Awareness. 
The  Shadow  COP  gets  its  name  because  it  is  “shadowing”  or  pulling  data  from  the 
current  Track  Management  System  (TMS)  but  adding  additional  information  from  other 
data  sources.  OTM  solves  a  number  of  performance  and  stability  problems  that  have 
existed  for  years  in  the  currently  deployed  COP.  In  addition,  it  sets  up  the  baseline  from 
which  a  number  of  new  capabilities  can  grow.  These  include  the  “attachment  points”  for 
new  capabilities  that  will  expand  the  COP  from  merely  a  track  picture  to  one  that 
provides  a  broad  range  of  situational  awareness  entities.  An  immediate  new  capability  is 
the  introduction  of  the  concept  of  “zone  management”,  wherein  zones  of  expertise  and 
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interest  are  created  to  facilitate  the  ambiguity  resolution  and  track  management 
problems  of  the  current  system. 
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Figure  6.  ISR  Data  Fusion  Pillar 


•  Intelligence  &  Collection  Management  Pillar.  The  third  pillar  of  the  maritime  C2 
initiative  is  the  Intelligence  and  Collection  Management  pillar  which  provides  C2  access  to 
sensors  and  collection  assets.  This  pillar  is  connected  strongly  to  the  ISR  Data  Fusion,  as 
was  shown  in  the  preceding  figures,  but  it  is  also  strongly  coupled  to  the  Planning, 
Execution,  and  Assessment  pillar.  Figure  7  depicts  the  operational  processes  of  the 
Intelligence  organization  as  coupled  to  the  Plans/Tasks  data  model.  In  essence,  the 
Intelligence  system(s)  should  accept  collection  requirements  from  the  Ops/Plans 
organization  and  should  populate  the  core  plans/tasks  data  model  with  the  appropriate 
red/white  force  and  environment  information  -  connected  in  a  way  that  provides  easy 
access  and  drill  down.  Note  that  the  Plans/Tasks  data  model  is  represented  in  this 
figure  in  a  symmetrical  way.  Blue  force  Courses  of  Actions  (COAs),  forces  and  specific 
actions  are  on  the  right  side  (shaded  in  blue),  and  the  equivalent  Red/White  force  COAs 
and  forces  are  on  the  left  (shaded  in  green).  The  Intel  analysts  produce  files  within 
GCCS-I3  that  describe  enemy  COAs  and  expected  Order  Of  Battle  (OOB)  in  the 
projected  operation  area.  The  initial  plan  is  to  ingest  those  products  and  permit  planners 
to  attach  them  to  the  corresponding  blue  products  within  the  Plans/Tasks  data  model. 
Then,  Red/White/Blue  information  is  accessible  through  a  single  access  mechanism. 
Only  the  top  level  products  are  actually  ingested,  and  the  more  detailed  products  are 
retained  in  the  GCCS-I3  data  stores,  with  pointers  to  those  products  held  within  the 
PTDS. 


For  the  targeting  and  combat  assessment  portion  of  the  Intelligence  organization, 
access  will  be  provided  to  candidate  targets  (potentially  subject  to  time  sensitive 
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targeting)  plus  nominated  and  approved  targets  from  the  Joint  Targeting  Toolbox  (JTT) 
as  an  application  on  GCCS-I3.  Combat  effectiveness  will  provide  access  to  OOB  status 
such  as  site  percent  effectiveness  and  facilities  operational  status. 

It  is  important  to  note  that  Collection  Management  (CM)  has  not  yet  been  developed. 
The  general  concept  is  shown  here  at  the  lower  right  corner  of  the  figure.  That  is, 
Information  Requirements  posted  in  the  Plans/Tasks  Data  set  are  created  during  the 
planning  process  and  may  be  related  to  such  items  as  the  Commander’s  Critical 
Information  Requirement  (CCIRs),  Priority  Intelligence  Requirement  (PIR),  Friendly 
Force  Information  Requirement  (FFIRs),  Measures  of  Effectiveness  (MOEs),  Measures 
of  Performance  (MOPs),  and  other  Requests  for  Information  (RFIs).  Information 
Requirements  become  Collection  Tasks,  which  also  are  represented  in  the  PTDS  as 
actions  (i.e.,  there  action  tasks  and  collection  tasks,  where  collection  tasks  may  be 
created  in  support  of  an  action  task  via  the  Information  Requirements  mechanism). 
Through  this  mechanism,  the  PTDS  and  COI  alert  function  will  eventually  be  able  to 
notify  decision  makers  when  collection  requirements  are  in  danger  of  not  being 
completed.  Again,  CM  is  a  future  capability  but  the  hooks  for  it  have  been  built  into  the 
architecture. 
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Figure  7.  Intelligence  and  Collection  Management  Pillar 

•  Force,  Unit,  Network  Capabilities  &  Readiness  Pillar.  The  fourth  and  final  pillar  is  the 
Capabilities  and  Readiness  Pillar  shown  in  Figure  8.  The  pillar,  which  provides  readiness 
status  and  insight  to  support  C2  mission  management,  is  comprised  of  three  distinct 
capabilities  that  work  together  to  answer  the  questions  of  “What  units  are  ready  and 
available  to  be  assigned  to  a  given  mission?”  and  “What  is  the  aggregate  readiness  to 
perform  a  mission”.  The  goal  of  both  questions  is  to  provide,  by  use  of  heuristics  that 
have  been  developed  and  manually  implemented  by  the  Fleet,  higher  quality  answers 
than  are  available  through  current  systems. 
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•  Blue  Force  Service  -  Units  and  Organizations:  Starting  at  the  top  center  of  the 
picture,  the  function  of  the  Blue  Force  Service  (BFS,  and  its  associated  Blue  Force 
Browser),  is  to  provide  access  to  authoritative  information  on  units,  platforms,  and 
systems.  The  “Units  and  Organizations”  portion  of  the  BFS  provides  information  on 
organizational  structures,  which  come  in  two  forms.  The  first  form  is  the 
Administrative  Control  (ADCON)  structure  that  represents  a  unit  as  trained, 
equipped,  organized,  and  deployed.  The  second  is  the  operational  and  tactical 
(OPCON/TACON)  form  of  the  unit  as  organized  under  the  receiving  commander.  It 
can  be  reconstituted  and/or  partitioned  from  its  ADCON  structure  to  meet  the  needs 
of  in-Theater  operations. 

•  Blue  Force  Service  -  platforms  and  capabilities:  The  Platform,  systems,  and 
capabilities  data  set  provides  reference  data  that  is  useful  in  selecting  forces/units  to 
assign  based  on  their  capabilities  (and  readiness),  and  it  provides  a  basis  for 
estimating  total  mission  readiness  (i.e.,  lack  of  readiness  due  to  lack  of  a  required 
capability  or  system  in  the  force).  Sources  for  this  portion  of  the  data  set  are  still 
being  identified.  Candidate  data  sets  include  those  currently  maintained  by  type 
commanders  and  the  shipboard  readiness  systems  that  feed  them. 
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•  Assessment  of  a  unit  or  platform  for  capability 
and  readiness  to  be  assigned 
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Figure  8.  Capabilities  and  Readiness  Pillar 

•  Readiness  COP:  The  Readiness  COP/Logistics  COP  is  a  combined  capability  that 
ingests  data  from  multiple  sources  (shown  in  the  figure)  and  summarizes  readiness 
both  as  a  roll-up  of  systems  within  organizational  units  (e.g.,  all  ships  and  air  wings  in 
a  task  group)  and  also  through  the  application  of  readiness  heuristics  (e.g.,  a  task 
force  is  not  ready  for  a  mission  unless  it  has  a  certain  ammo  load  out,  certain  specific 
systems,  and  a  certain  number  of  platforms  with  a  specified  capability).  The 
LogCOP  connection  provides  the  status  of  mission  areas  as  well  as  access  to 
Casualty  Reports  (CASREPTs)  on  problems  causing  the  readiness  degradations. 
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The  “palette”  of  readiness  is  a  “Plans/Missions  Readiness  Dashboard”.  At  the  lower  left  in 
the  Figure  8,  the  Task  Navigator  serves  as  the  low  level  function  of  selecting  and  updating  a 
unit,  platform,  or  resource  (capability)  for  assignment  to  a  task.  Its  requirements 
(force/capability  needs)  come  either  from  the  Priority  Mission  Service  or  the  Decision  Point  tool; 
and  the  forces  are  selected  through  a  browsing  operation  within  a  COP,  followed  by  task 
assignment  within  the  Task  Navigator. 

Maritime  C2  Implementation  Plan 

The  incremental  development  approach  implemented  by  PMW-150  is  shown  in  Figure  9. 
Simply  stated,  it  is  the  addition  of  planning,  execution,  and  assessment  capabilities  into  the 
maritime  C2  Programs  of  Records  (PORs)  which  will  enable  and  facilitate  the  collaborative, 
distributed  management  of  operations.  This  approach  employs  a  C2  technology  insertion  and 
rapid  prototyping  model  that  not  only  supports  the  CNO’s  2010  intentions  but  achieves  the 
Guiding  Principles  and  Tenets  presented  in  the  Vision  for  U.S.  Navy  Information  Dominance, 
reference  (a). 


C2  Oblectlve 

•  Produce  a  shared  situation 
display  that  Includes  not  lust 
fbrce/unlt  locations  but 
force/unit  tasks,  task  status, 
and  progress  toward 
achieving  overall  objectives. 

...  or,  In  other  words, ... 

•  Move  our  Maritime  C2 
systems  from  “Who,  & 
Where?*  to  ‘Who.  What 
When.  Where,  Iflfljy,  & 
How?* 


COMPACFLEET,  JTF,  JFMCC  MOC 


What  is  this  unit  tasked  to  do? 
Against  what  target ? 


How  are  his  tasks  synchro¬ 
nized  with  his  Force  tasking ? 


Are  there  any  readiness, 
ogistics.  NetCOP.  METOC 
or  Task  Sync  conflicts ? 


What  is  the  task  status  & 
mission  effects  status ? 


\Z7  ii  / 

srs  •  Are  there  alternate  resour-ces 

v  i  that  could  be  assigned? 

XIu _ i  r~7  SZL _ 1 1  s' - 


Commanders  Control  Measures 


/  AffufonJItomt-arnuaatf 
*  MarntmeMtsston  Ar**s 

i— l  r - l  rT-— 


\  JFMCC  /  XCTF/CTG/  Y_CV_/  \  ^  /  CSfc/  \  FFG  / 


Figure  9.  Synchronizing  the  World  of  Maritime  C2 

There  are  two  key  precepts  that  underpin  the  incremental  development  roadmap.  The  first 
is  that  Maritime  C2  Planning  and  Guidance  are  centrally  generated  but  that  execution  planning 
and  execution  are  carried  out  in  a  decentralized  manner  at  the  tactical  level.  The  second 
precept  is  that,  in  accordance  with  Maritime  Doctrine  (NWP  3-32)  the  OLW  commander  must  be 
equipped  to  monitor  the  status  of  control  actions  (or  C2  interventions)  in  six  control  areas,  or 
categories,  to  ensure  that  the  decentralized  execution  is  proceeding  in  a  manner  synchronized 
with  the  Commander’s  intent  and  the  advancement  of  the  plan  in  alignment  with  the 
commander’s  strategy.  The  manifestation  of  these  activities  is  shown  in  the  Maritime 
Operations  Center  (MOC),  where  watch  standers  are  able  to  access  the  who,  what,  when, 
where,  why,  and  how  as  shown  by  the  example  questions  being  asked  of  the  staff  in  the 
summary  displays. 
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The  Maritime  C2  Implementation  Plan  is  shown  in  Figure  10  and  is  driven  by  two  inter¬ 
related  initiatives:  the  Command  and  Control  Rapid  Prototyping  Continuum  (C2RPC)  and  the 
Command  and  Control  Technology  Insertion  Initiative  (C2TII). 

•  C2RPC.  ONR  and  PMW-150  funded  series  of  experiments  and  prototypes  designed  to 
produce  enhanced  operational  concepts  and  capabilities  in  the  areas  of  C2  of  joint  and 
combined  maritime  forces. 

•  C2TII.  A  PMW-150  effort  to  move  the  Global  Command  and  Control  System  -  Maritime 
(GCCS-M)  (Fleet,  Force,  Group/Unit  variants)  program  from  its  current  focus  on  a  wide 
area  COP/SA  distribution  toward  a  greater  capability  for  planning,  execution,  and 
assessment  across  the  range  of  platforms  and  commands.  C2TII  seeks  to  prototype  a 
“reachback”  enhanced  C2  capability  in  FY 10/11  and  a  shipboard  and  shore  base 
installation  in  FY12/13. 

As  much  as  possible,  PMW-150  desires  that  C2RPC  technologies,  along  with  other 
promising  technologies,  transition  into  the  C2TII  effort  for  hardening  and  Development  Test 
(DT)/Operational  Test  (OT)  before  deployment  to  GCCS-M  and  MTC2.  The  technical  concept 
for  C2RPC  and  C2TII  can  be  viewed  as  a  viewport  to  the  four  pillars  described  above  and  the 
relationships  among  them. 

The  Figure  10  graphic  shows  the  relationship  between  the  two  initiatives  and  shows  the 
expected  feed  of  new  technologies  from  C2RPC  to  C2TII  for  insertion  in  C2  products  and  then 
the  feeding  of  stable  C2  products  from  C2TII  to  C2RPC. 
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Figure  10.  C2RPC  and  C2TII  Evolution 


The  upper  part  of  the  figure  (highlighted  in  red)  depicts  a  number  of  “Tracks”,  or  efforts  to 
pilot  science  and  technology  (S&T)  capabilities  at  various  operational  commands.  The  focus  of 
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the  C2RPC  initiative  is  on  experimentation  and  on  informing  the  production  programs  of 
methods  and  means  for  achieving  the  doctrinal  C2  process  requirements.  To  achieve  its  goals, 
the  C2RPC  initiated  a  “Track  1”  effort  at  COMPACFLEET  in  2010  designed  to  assess 
requirements  and  technologies  at  the  Fleet  Commander/Naval  Component  Commander-level. 
Subsequently,  other  spirals  (e.g.  the  Track  2  JFMCC/TF/TG  prototype  and  the  DIL  unit’s 
prototype  are  planned  over  a  development  cycle  that  parallels  the  C2TII  threads  and  the 
associated  GCCS-M  DT/OT  cycles. 

The  lower  portion  of  the  figure  (highlighted  in  blue)  represents  the  “Transition  Track”.  It  is 
here  that  developmental  capabilities,  derived  from  S&T  and  other  requirements,  are  hardened 
for  transition  to  formal  POR  releases.  The  Figure  shows  four  increments  -  2011,  2012,  2014, 
and  2016,  along  the  path  to  full  operational  capability  of  the  C2TII  capability  in  GCCS-M. 

GOVERNMENT  OWNERSHIP  AND  TECHNICAL  CONTROL  OF 
SOFTWARE  ACQUISITION  PROCESSES 

The  final  strategic  objective  involves  the  software  acquisition  process  changes  that  have 
been  implemented  by  PMW-150  to  support  the  Maritime  C2  Roadmap.  This  Initiative  is  called 
the  Rapid  Integration  and  Testing  Environment  (RITE)  and  it  improves  software  development 
and  testing  activities  through  an  environment  that  combines  software  development,  integration, 
testing  and  support  together  using  state-of-the-art  integration  and  testing  processes  and  tools. 

The  RITE  is  changing  PMW  150’s  software  development  methodology  and  modernizing  the 
development  process.  Its  goal  is  to  reduce  overall  cost,  streamline  delivery  of  quality  C2 
software  and  ultimately  to  focus  resources  toward  the  early  stages  of  the  life  cycle  where  the 
return  on  investment  is  maximized.  Since  its  inception  in  2008,  the  RITE  has  demonstrated  its 
ability  to  dramatically  cut  development  time  by  identifying  software  defects  earlier  in  the 
development  process  where  they  are  easier  and  less  expensive  to  correct. 

The  RITE  is  based  upon  four  basic  principles: 

•  Software  Development  Contracts.  The  need  to  provide  detailed  system  requirement 
specifications  and  acquire  favorable  product  licensing  agreements; 

•  Process  improvement.  The  adoption  of  industry  software  engineering  best  practices; 
testing  early  and  often  to  detect,  track  and  correct  software  defects  while  the  impact  on 
project  cost  and  schedule  is  minimal; 

•  Infrastructure  development.  The  establishment  of  a  centralized  repository  with  web 
interfaces  to  streamline  and  automate  product  testing,  information  sharing,  and  end- 
product  distribution;  and 

•  Organizational  change.  The  alignment  of  technical  skills  and  staffing  levels  to  support 
new  life  cycle  processes. 

RITE  Contract.  A  baseline  requirement  for  RITE’s  implementation  is  the  adoption  of 
specific  contract  language  that  changes  the  existing  relationship  between  the  prime 
software  developer  and  the  Government  project  team.  New  contracts  address  the 
following  contract  stipulations. 
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•  Requirement  Definition.  The  Government  assumes  responsibility  for  developing 
the  system  requirements  and  baseline  design  specifications  used  by  the  software 
developer  and  the  Government  project  team  for  contract  performance.  These 
requirements  are  based  upon  operational  requirements,  involve  stakeholders  in 
the  process,  and  are  at  a  level  of  specificity  that  provides  developers  and  testers 
product  acceptance  criteria. 

•  Licensing  Agreement.  The  Government  obtains  either  “Government  Purpose 
Rights”  or  “Unlimited  Rights”,  as  defined  in  Defense  Acquisition  Acquisition 
Regulations  (DFARS)  and  applicable  agency  supplements,  for  all  non¬ 
commercial  computer  software  items  developed  with  Government  funding.  This 
includes  the  delivery  of  software  source  code  and  related  software  version 
design  documentation. 

•  Process  Adherence.  The  Government  mandates  that  use  of  the  RITE  life  cycle 
processes  through  the  Statement  of  Work  (SOW).  New  SOW  language  includes: 
o  Contract  Data  Requirements  Lists  (CDRLs)  and  Data  Item 

Descriptions  (DIDs)  that  define  an  expanded  set  of  delivered 
software  work  products,  including  source  code  and  software  version 
documentation; 

o  Streamlined  test  processes  requiring  the  use  of  automated  tools  and 
focused  testing  procedures; 

o  Contractor  Performance  Acceptance  Reporting  System  (CPARS) 
metrics  that  satisfy  RITE  entrance  and  exit  acceptance  criteria; 
o  Specified  Quality  Management  (QM)  and  Configuration  Management 
(CM)  procedures; 

o  Implementation  of  disaster  recovery  techniques;  and 
o  Software  auto-installation  capability. 


RITE  Process.  The  RITE  Product  Life  Cycle  (PLC)  is  shown  in  Figure  1 1 .  Major  changes 
from  the  existing  life  cycle  are  the  coupling  of  the  Implementation  and  Test  stages  and  the 
direct  involvement  of  the  software  support  activity  (SSA)  project  team  in  software 
development.  Both  stages  are  integrated  as  part  of  the  RITE  process;  aligning  early  defect 
detection,  tracking  and  resolution  with  development  activities.  The  RITE  life  cycle  includes 
implementation  of  front-end  engineering,  source  code  quality  management,  a  distributed 
development  environment,  and  automated  development  and  test  tools. 
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Figure  11.  RITE  Life  Cycle  Model 
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RITE  Infrastructure.  A  Distributed  Development  Environment  (DDE)  is  a  virtual 
collaborative  environment  that  spans  multiple  organizations  and/or  multiple  physical 
locations.  In  a  DDE,  project  members  share  ideas,  information  and  resources,  and 
actively  collaborate  to  achieve  a  common  goal.  The  primary  advantage  of  DDE  is 
availability  of  resources  and  access  to  software  development  tools  from  different 
locations.  The  objective  is  to  lower  development  costs,  increase  productivity,  decrease 
time-to-release,  and  improve  product  quality. 

The  hub  of  the  RITE  DDE  infrastructure  is  the  Development  and  Distribution  (D2) 
Center.  The  D2  Center  allows  access  to,  and  sharing  of,  applicable  Navy  C2  program 
software,  test  tools,  program  governance  and  guidance  documentation  and  other  project 
technical  documentation  generated  as  part  of  the  RITE  life  cycle  process.  Developers, 
testers,  and  other  stakeholders  have  access  to  the  Center  through  a  private  cloud  using 
a  web-based  interface  and  a  set  of  intuitive  tools  for  locating  and  extracting  desired 
components  and  associated  work  products.  The  D2  Center  provides  strong 
configuration  control  of  the  various  project  artifacts  and  assures  that  contractor  and 
Government  teams  are  working  from  a  common  set  of  project  components. 

The  D2  architecture  is  shown  in  Figure  12  and  takes  advantage  of  an  open 
architecture  to  support  the  following  project  functions: 

•  Government  management  of  key  project  artifacts; 

•  Management  of  source  code; 

•  Definition  and  management  of  the  development  and  integration  environment; 

•  Configuration  Management  (CM)  for  validation  and  control  of  software  deliveries; 

•  Support  tool  development; 

•  Architecture;  and 

•  Guidance  and  governance  documentation. 
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RITE  Organization.  Lastly,  one  of  the  key  components  of  the  RITE  initiative  is  the 
organizational  change  needed  to  efficiently  and  effectively  perform  within  the  new  life 
cycle  model.  The  current  project  structure  has  evolved  to  support  existing  processes 
with  personnel  skill  sets  optimized  for  the  needed  job  task  capabilities.  As  the  PLC 
changes,  increasing  the  need  for  more  software  engineers  and  reducing  the  number  of 
fleet  installation  teams,  the  organizational  core  competencies  need  to  change.  The 
projected  changes  include: 

•  Project  Manager  Performance  Measures.  New  performance  metrics  are 
needed  for  the  project  management  team.  In  a  distributed  work  environment 
where  success  is  dependent  upon  frequent  communication  and  collaboration, 
success  factors  need  to  moderate  the  current  competitive  environment. 
Additionally,  success  should  be  measured  by  program  efficiencies  and 
effectiveness  that  result  in  budget  optimization  not  by  overall  program  budget 
size. 

•  Personnel  Qualifications.  The  Government  currently  lacks  sufficient  qualified 
personnel,  either  educated  or  trained  in  the  software  engineering  disciplines,  to 
perform  the  new  job  task  functions  required  by  RITE.  These  technical 
qualifications  include  knowledge  of  current  operating  systems,  databases,  and 
functional  applications.  Of  importance  are  skills  associated  with  open 
architecture  development  and  web  design.  A  staff  transition  needs  to  begin, 
selecting  a  cadre  of  technically  qualified  software  engineers  to  lead  the  workforce 
shift  from  current  methods  and  processes  while  initiating  focused  recruitment  and 
training  programs. 

•  Organizational  Structure.  Lastly,  in  addition  to  the  personnel  qualifications,  the 
project  organizational  structure  needs  to  evolve  to  meet  the  changing  life  cycle 
model.  Under  RITE,  the  staffing  levels  associated  with  software  development 
and  testing  will  need  to  grow  to  meet  the  increased  level  of  effort  and  product 
throughput  associated  with  those  stages.  Conversely,  although  not  immediate, 
there  will  need  to  be  a  reduction  in  staffing  associated  with  installation  and 
integration  activities  performed  during  the  Maintenance  stage. 

SUMMARY 

PMW  150,  as  the  C2  Program  Manager,  has  developed  and  is  begun  implementing  a  new 
Maritime  C2  Strategy.  This  strategy  has  three  primary  objectives  designed  to: 

1 .  Provide  the  warfighter  the  tools  needed  to  access  the  C2  information  to  make  informed 
decisions.  The  new  tools  will  support  the  Commander’s  decision  cycle  by  allowing  them 
to  manage  their  six  control  areas:  Maintain  Alignment,  Adjust  Apportionment,  Advance 
the  Plan,  Comply  with  Procedure,  Situational  Awareness,  and  Counter  the  Enemy. 

2.  Transition  the  current  stove-pipe  C2  systems  to  a  service-based  architecture  using  a 
component  portfolio  approach  which  provides  a  foundation  for  development  and 
insertion  of  independently  components.  This  objective  supports  the  Navy’s  objectives 
for  Information  Dominance. 

3.  Establish  government  technical  control  and  ownership  of  the  software  products  that  it 
pays  to  development.  This  is  done  through  to  the  product  life  cycle  integrating  early 
testing  into  the  software  development  process  and  has  shown,  in  a  short  period  of  time, 
to  have  substantial  return  on  investment  by  reducing  the  time  it  takes  to  develop  and  test 
new  software  components. 
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